【資料公開】PCI DSSの認証取得を目指す方へ！AWSの利用を前提としたパッチ管理について考えるクローズドな勉強会をやりました

どーも、PCI DSS初心者の中山（順）です。

先日、社外の方（とあるQSA（認定審査機関）の中の方たち）とAWSのセキュリティ機能を勉強するクローズドな会を実施しました。 せっかくなので、その際の資料をこちらで共有したいと思います。 併せて、PCI DSSの概要についてもご紹介します。

これからPCI DSSの認証取得／準拠を考えている方、もしくは認証取得まではしないがそれに準じた対策を考えている方に読んで頂けると幸いです。

そもそもPCI DSSとは？

PCI DSSとは、加盟店（店舗、ECサイトなど）やサービスプロバイダ（決済代行事業者など）において、クレジットカード会員データを安全に取り扱う事を目的として策定された、クレジットカード業界のセキュリティ基準です。

PCI DSSとは

なぜ認証を取得するのか

昨今、様々な企業においてクレジットカード情報の漏洩事故が発生していることは皆さんもご存じかと思います。 特定の事件を取り上げるのは差し障りがありますので、みんな大好きpiyologさんなどをご覧頂ければと思います。

piyolog

こういった背景を踏まえ、改正割賦販売法が公布／施行されました。

割賦販売法（後払分野）の概要・FAQ

この改正割賦販売法において、以下のことが求められています。

問１ 改正割賦販売法（H28年12月公布・H30年6月施行）の主な内容はどのようなものですか。

改正後の割賦販売法（以下「改正法」という。）では、クレジットカードの発行を行う会社と、販売業者と契約を締結する会社が別会社となる形態の増加に伴いクレジットカードを取り扱う販売業者の（加盟店）管理が行き届かないケースが生じていることや、その結果により加盟店におけるクレジットカード番号等の漏えい事件や不正使用被害が増加していること等を踏まえ、安全・安心なクレジットカード利用環境を実現するために必要な措置を求めています。

具体的なポイントは以下の３点です。

（１）加盟店管理の強化

加盟店に対しクレジットカード番号等を取り扱うことを認める契約を締結する事業者（アクワイアラー等）について、登録制度を創設するとともに、加盟店への調査等を義務付けます。

（２）加盟店におけるセキュリティ対策の義務化

加盟店に対し、クレジットカード番号等の適切な管理やクレジットカード端末のIC対応化等による不正利用防止対策を義務付けます。

（３）フィンテックの更なる参入を見据えた環境整備

アクワイアラーと同等の位置付けにある決済代行業者も、アクワイアラーと同一の登録を受けられる制度を導入します。また、加盟店のカード利用時の書面交付義務を緩和します。

割賦販売法（後払分野）の概要・FAQ

このように、クレジットカード情報の適切な管理が義務付けられています。

具体的な対策に関しては、経済産業省より実行計画として指針が示されています。

クレジットカード取引におけるセキュリティ対策の強化に向けた「実行計画2019」を取りまとめました

最新の実行計画では、「クレジットカード情報保護対策」として以下のような対策が示されています。

• 加盟店におけるカード情報の「非保持化」
• カード情報を保持する事業者のPCI DSS準拠
• 新たな脅威への警戒とセキュリティ対策への継続的な取組の推進

このような背景もあり、弊社でもPCI DSS準拠を目指すお客様をサポートできるようPCI DSSについての継続的な学習を行っています。

勉強会について

この勉強会では、AWSのセキュリティ機能をクラスメソッドのメンバーが紹介し、とあるQSAの中の方たちと「どのくらいPCI DSSの要件に対応できるか」「現実においてはどのような運用をすることになりそうか」というディスカッションを行いました。

なお、今後も勉強会は定期的実施することを予定しています。

今回のテーマは、「プラットフォームの脆弱性管理／パッチ管理」でした。

ここではその際に紹介した機能をご紹介します。

資料

資料はこちらです。

私からはSystems ManagerのPatch Managerを紹介しました。

PCI DSSにおけるパッチ管理の要件

PCI DSSにおいては要件6.1および6.2でプラットフォームにおける脆弱性対策が求められています。

6.1では脆弱性を収集し、識別とランク付けを行うプロセスの確立を求めています。

6.2ではセキュリティパッチの速やかな適用によるリスク緩和を求めています。

Systems Managerによるパッチ管理

AWSではEC2の管理を行うSystems Managerがあります。

その中のPatch Managerを利用することでPatch Baselineに基づいた脆弱性の検出が可能です。 検出された脆弱性は、Patch Managerによって脆弱性の深刻度やCVE IDなどの属性が付与され、識別とランク分けが可能になります。（要件6.1）

また、Maintenance Windowを利用することで脆弱性の検出とセキュリティパッチの適用を自動化することも可能です。 セキュリティパッチの適用については、Session ManagerやRun Commandで実施することも可能です。（要件6.2）

Patch Managerの使い方

資料では、以下の順に機能を紹介していきました。

• EC2インスタンスの作成 / インスタンスプロファイルのアタッチ
• パッチベースラインの確認
• メンテナンスウィンドウの作成、動作確認（パッチ適用状況の確認のみ）
• Managed Instanceの構成情報を確認
• メンテナンスウィンドウの修正、動作確認（インストール）

EC2インスタンスの作成 / インスタンスプロファイルのアタッチ

Patch Managerを利用するにはSSM Agentと適切な権限を付与したIAM Roleが必要です。 言い換えると、必要なのはそれだけです。 しかも、一部のOSについてはSSM AgentがAMIに構成済みなので、IAM RoleさえアタッチすればOKです。 はじめるのは非常に簡単。

パッチベースラインの確認

Patch Baselineとは、脆弱性を脆弱性として認識するかどうかの基準です。 脆弱性の深刻度やパッチの分類などを利用して定義することができます。

予め用意されているものを利用することも、独自に定義することも可能です。 また、パッチを個別に管理対象としたり除外したりすることも可能です。 ただし、PCI DSSにおいてパッチの適用基準を独自に設定すること自体は問題ありませんが、客観的な指標に沿った判断が求められることに注意する必要があります。

メンテナンスウィンドウの作成、動作確認（パッチ適用状況の確認のみ）

セキュリティパッチ適用状況の確認および適用が可能です。 セキュリティパッチ適用状況の確認のみを実行することも可能です。

インスタンス内で実行する処理内容については、SSM Documentとして予め定義されています。

実行スケジュールは、Maintenance Windowの設定内で実行周期もしくはcron式で指定することができます。

Managed Instanceの構成情報を確認

脆弱性スキャンを実行すると、その結果はインベントリーとして収集／保存されます。 どのパッケージのどのバージョンがいつインストールされたか、などを確認することが可能です。 また、Patch Baselineに基づいて、パッケージ毎にComplimentかNon-Complimentかを識別できます。

メンテナンスウィンドウの修正、動作確認（インストール）

また、Maintenance Windowの設定次第では、セキュリティパッチの適用状況の確認だけでなく、セキュリティパッチの適用まで実施することも可能です。 ちなみに、Patch Baselineの設定次第では、セキュリティパッチのリリースから指定した日を経過してから適用状況の確認／適用の対象とすることもできます。

ディスカッション

ディスカッションでは、「パッチ適用状況の確認としては利用できそう」「適用後に既存の業務アプリに影響がないか検証環境等で動作確認する必要があり、適用まで自動化するのは難しいケースが多いと思う」「リスクが可視化できて良い」などの意見が出ました。

QSAの立場から見ても、有用な機能であるとのコメントを頂きました。 なお、ここまで上げさせていただいた活用法はあくまで一つの想定環境での話のため、PCI DSSの要件に適用できるかどうかはQSAに相談してみてください。

まとめ

Systems Managerは地味ですがとても強力な機能で、付加価値の低い作業に要する工数を大きく減らしてくれます。 パッチ管理自体はビジネス的な価値を直接生むわけではないので、できるだけコストはかけたくないところです。 もちろん、ビジネス上のリスクを緩和する重要なタスクではあります。 PCI DSSではこれ以外にも多くの要件がありますが、人力でやろうとすると大きな負担になります。 定型化できる作業は逐次自動化するなどして省力化を図りつつ、ビジネスリスクを低減していきましょう。 AWSを使うことで、それは実現できます。